VB for Linux: The Virtues of Front-End Tools

Mark Leighton Fisher on 2006-04-14T16:56:21

IMHO, Linux et.al. could really use a Visual Basic-like tool, especially for writing those programs that are essentially, specialized database objects with a GUI. Personally, I would be happy with such a tool if it was Perl-based, as I find Perl to be a highly productive language. However, I can see reasons why a modern, O-O Basic is a good language for such a tool (and sometimes better – but see below).

I think that many if not all of these features are present in the Linux world, but no system combines all or even most of these features. Ease of development is the theme of this combination of features – an ease that has not only made Visual Basic one of the leading development environments, but indirectly (IMHO) stimulated interest in development frameworks like Catalyst and Ruby on Rails.

VB's simple event/message interface is a key reason why developers find VB so productive. There might be a simpler way to map events to functions in an IDE, but I don't know what it would be. The Visual Studio IDE lets you select a control is one listbox, which then limits the events in a second listbox to only the events used by that control. As someone who remembers fussing with message loops in Windows C programs, this is a godsend. Although there are cases when you need to directly manipulate the Windows message loop, those cases are not the majority of cases (10%?  1%?) For most programs that will be written for Windows, the Visual Basic model of a hidden message loop encapsulated by listbox-selectable events works fine. "With Events" also deserves mention, as With Events hooks into VB's IDE so that you merely need to select the "With Events" object from a listbox, then select the event(s) of interest from the second listbox to create the code skeleton for that event.

Data binding is another big feature of VB, as you can directly bind your data to a control, skipping database programming for that piece of data entirely. Since so much of user-facing programming consists of database interfaces as alluded to above, this is a Big Deal.

Controls and their properties are another reason programmers often turn to Visual Basic. You drop a control onto a form, tweak a few properties, and voila – you have a functioning control. Properties also provide a natural mechanism for data validation. (Note how ease-of-development keeps popping up here...)

Visual Basic keeps track of a lot of the niggling details of building an application or a DLL. VB.NET then adds detecting multiple errors in a build (how I miss that when I use VB6), integrated unit-testing, and integrated code coverage. Although you can't specify individual tests to run in VB.NET, you can specify to only re-run tests that just failed (which is good enough for a lot of purposes). I would even give a slight edge to VB.NET unit-tests because (when I was comparing them several months ago), VB.NET had regular expression tests but NUnit did not – I was OK with giving up the "run individual test" facility to gain regular expression-based tests.

Visual Basic is a wordy language that misses some shortcuts found in Perl, C++, etc. used to make your programs more concise. However, this wordiness, along with Visual Basic's simple syntax, makes it possible for the logically-minded non-programmer to grab ahold of enough of the language to get useful work done, while making it one of the easiest languages for a computer professional to pick up. I wonder how many C, C++, and Perl programmers now do much of their coding in Visual Basic?

Visual Basic's theme is ease-of-development. I am reasonably sure that all of the features I've outlined above are available in the Linux and/or Open Source worlds, but as far as I know there is no system that combines most of these features. I smell a business opportunity here (remember, you can sell GPL software – you just have to provide source code...)


But first...

Alias on 2006-04-14T18:08:44

Well, I think the reason we're a bit short of that goal is that Perl is cross platform, and "Desktop Perl" is still not quite there yet.

The last big blocker for my Perl Editor grant is exactly that.

Win32 Perl isn't quite there yet, although with a big of luck Strawberry Perl will solve that, and none of the GUI toolkits are quite there either (although Wx is the closest, and I know the author is trying to bridge the last gaps to being as easy to install as, say, SQLite).

So there's no reliable combination of parts that you can write and have just install and work on the three big desktop platforms (Windows, Mac OS X, Freenix).

As for GUI designers, some people have had good results with Glade for the front-end. But yes, there's no obvious equivalent.

But I think we are now at the point where "Desktop Perl" is not an unreachable goal.

How much of that is true without visual studio etc

TeeJay on 2006-04-14T20:09:27

really - Visual Studio makes it drag and drop, OLE and a dozen other proprietary add ons make it easy. The VB isn't that important.